Now 21 2005 4»06P H YEE 8. RSSOCIflTES, P.C. (972) 385-77S6 p.l 

■■ ' RECEIVED 

CENTRAL FAX CENTER 



Yee& 

Associates, P.C. 



4100 Alpha. Road 

Suite 1100 

Dallas. Texas 7S244 



NOV 2 1 2005 

Main No. (972) 385-8777 
Facsimile (972) 385-7766 



Facsimile Cover Siieet 



To: Commissioner for Patents for 

Examiner Mohammad A, Siddiqi 
Group Art Unit 2154 


Facsimile No.: S71/273-8300 


From: Michele Morrow 

LeRal Assistant to Francis Lammes 


No. of Pages Including Cover Sheet: 33 


Message: 




Enclosed herewith: 




• Transmittal Document; and 

• Appeal Brief. 




Re: Application No. 09/740^6S 

Attorney Docket No: AUS9-2000^592-US1 


Date: Monday, November 2 1 , 2005 


Please contact us at (972) 385-8777 If 
you do not receive all pages 
Indicated above or experience any 
difGculty in receiving this facsimile* 


This Facsimiie b intended onfy for the use of the addressee 
Ofui, if the addressee is a client or their agmt, contains 
privileged and confldemt(d informatioPL If you are not the 
immded recipient of this facsimile^ you have received this 
facsimile inadvertemfy and in error. AJiy review, 
dissemination^ distribution, or copying » strictfy prohtbUed. 
^you received this facsimile in error, please not]fy us by 
telephone and return the facsimile to us immediately 



PLEASE CONFIRM RECEIPT OF XmS TRANSMISSION BY 
FAXING A CONFIRMATION TO 972-385-7766. 



PAGE 1/33 ' RCVD AT 11/2112005 4:02:28 PM [Eastern Standard Time] * SVR:USPTO{FXRF-6/27 ' DNIS:2738300 * CSID:972 385 7766' DURATION ^m-s$):07-40 



Now 21 2005 410BPM YEE & flSSOCIRTES, P.C. (9721 385-7766 



m TBffi tNTTED ^ATES PATENT AND TRADEMAltK OFFICE 



In re application of: AiiandetAL 



§ 
§ 
§ 
§ 
§ 
§ 

§ 
§ 



Group Art Unit 21S4 



Serial No.: 09/740,565 



Examiner: Siddiql, Mohammad A. 



Filed: December 18, 2000 



Attorney Docket No.: A^JS9-2000-OS9^US1 



r 



I . C»aflt.teoflV»i>iBri«ll(>llUnH *ra7r-F.R. »\Me.\ , 

I hoeby oerd^ diis coneipondence ii being trtnamlned via fbeilmile to 
I On ConiiniBsioiier for P«en1», P.O. Box 1450, Alexuidiu, VA 22313- 
1 1450. fec»taUenuJ5iber<571)273-8J0O on NovBi*er21, 2005. 



For: M^hod, Ai^aratns, and 
Program for Server Based Netnrork 
Computer Load Balandiig Across 
Moltlple Boot Servert 



By. 



3 5525 




TRANSMITTAL DOCUMENT 



Commissioner for Patents 
P.O.Box 1450 
Alexandria, VA 22313-1450 

Sir: 

BNCLOSBD HBREWrrai 

Appeal Brief (37 C J?.R. 41 37). 

A fee of S500.00 ifi required for filing an Appeal Brief. Please charge this fee to IBM Corporation 
Deposit Account No. 09-0447. No additional fees are believed to be necessary* If» however, any addhioiial 
fees are required, I authtirize the Qmiiniasioner to charge Ifaese fees .which may be required to IBM 
Oorporation iDeposit Account No. 09^0447. No extension of time is believed to be necessary. If, however, 
an extension of time is required, the extension is te<)iiested, and I authorize the Connznisaioner to charge any 
fees for this extengiidn to IBM Corporation Deposdt Account No. 09-0447. 



Francis Lammes 
Registration No. 55,353 
Agent for Applicants 




DukeW.Yee 
Registration No. 34,285 
Attorney fbr Applicants 



Yee & Associates, P.C. 
P.O. Box 802333 
Dallas, Texas 75380 
(972)385-8777 



PAa2ra*RCVDAT11/21/2005 4:02:28PM[EastemStM^ 385 7766* DURATION (inrn-ss):0740 



Now 21 2005 410GPH YEE 8< HSSOCIflTES, P.C. (972 J 385-7766 



Docket No. AUS9-2000-0592-tJSl PATENT 

RECEIVED 

IN THE UNITED STATES PATENT AND TRADEMARK OFFICE CENTRAL FAX CENTER 

NOV 2 1 2005 

In re application of: Anand et aL § 

§ Group Art Unit: 2154 

Serial No, 09/740,565 § 

§ Examiner: Siddlqi, Mohammad A. 

Filed: December 18, 2000 § 

§ 

For; Method, Apparatus, and Program § 
for Server Based Network Computer § 
Load Balancing Across Mult^le Boot § 
Servers § 



Commissioner for Patents 
P*0. Box 1450 
Alexandria, VA 22313-1450 



ll/Ea/2005 STEURELl 00000053 090447 09740565 
01 FC:1402 500.00 Dfl 



rertttteite Df TYfti»irt(»ton Ui»lcr37CF>K 6 l^fa) 
I licrvby ccztiiy ihifl CQ i ' Bwp o n denoq Is being httnsmlttad via 
facsimne to the Commissioner for P&tcmt9, P.O. Box 1450, 
Al«xandri^ VA 22313-1450. fewimlle number (571) 273-8300 
onNovftiiibv21,30€l 

3y: 



MichGls Mbctow 
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REAL PARTY TS INTEREST 

The real party in interest in this appeal is the following party: International Business 
Machines Corporation, 
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RFXATED APPEALS AND rVTERFERENCES 

With respect to other appeals or interferences that will direoay affect, or be directly affected 
by, or have a bearing on the Board's decision in the pending appeal, there are no such appeals or 
interferences. 



(i^peal Brief P<ge 3 of 31) 
AiiMide(al.-09/740.S65 

PA(XSf33'R(M)AT11/21l20054:02:28PM{Easteni Standard Tiine]'SVR:USPTO?^ 



Nov 21 2005 4107PM YEE 8< flSSOCIflTES, P.C. (372J 385-7766 



p,6 



A- TOTAL NUMBER OF CLAIMS IN APPUCATION 



Claims in the application are: 1-26. 

B. STATUS OF ALL THE CLAIMS IN APPLICATION 



L Claims canceled: NONE. 

2. Claims withdrawn from consideration biit not canceled: NONE. 

3. Claims pending: 1-26. 

4. Claims allowed: NONE. 

5. Claims rejected: 1-26. 

6. Claims objected to: NONE. 



C, CLAIMS ON APPEAL 

The claims on appeal are: 1-26. 
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STATUS mr AMENPMENTS 

There are no amendments after the final rejection dated August 10, 2005. 
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SUMMARY OT CXAIMED S TTT^TKrT MATTER 

Independent claims 1, 14, and 25: 

The present invention provides a method for retrieving client boot infomiation in a network 
environment with multiple boot servers. (Specification, page 22, lines 12-16) The present 
invention initiates at a client an initial request for client configuration information. (Specification, 
page 22, lines 16-17, and pages 19, lines 27-29) The present invention sends from the client the 
initial request for client configuration informatioii to a first boot scxvcar. (Specification, page 22. 
lines 16-17, and page 19, Une 27 to page 20, line 2) The present invention receives at the client a 
boot server list if the client configuration information is not found on the first boot server. 
(Specification, page 23, lines 7-10, and page 20, lines 3-9) The present invention sends fix)m the 
client a configuration information request for the oUent configuration information to each server in 
the boot server list until the client configuration information is found or a request has been sent to 
every server in the boot server list. (Specification, page 23, line 10 to page 24, line 5, and page 20. 
line 10, to page 22, line 1 1) 

The means lecited in independent claim 14, as well as dependent claims 15-20, may be data 
processing hardware within server 104 or clients 108, 110, and 112 in Figure 1 operating under 
control of software performing the steps described in the specification at page 22, line 12, to page 
24, Une 5, or equivalent* A person having ordinary skill in the art woixld be able to derive computer 
instructions on a computer readable medium as recited in claim 2S given Figures 9-12 and the 
correspon^g description at page 22, line 12, to page 24, line 5, without undue experimentation. 

Independent claims 10^ 21, and 26: 

The present invention provides a method for providing client boot infoamation in a network 
environment with multiple boot servers, (Specification, page 22, lines 12-16) The present 
invention receives at a boot server an initial request for client configuration information flx)m a 
client,, wherein the initial request is initiated at a client. (Specification, page 22, lines 16-21, and 
page 19, line 30, to page 20, line 2) The present invention sends from the boot server the boot 

(Appeal Brief Page 6 of 31) 
Anandetal. -09/740.565 



PAGE8/33*RCVDAT11/21/20054:02:28PMpstemSto^ 385 7766* DURATION (mm-ss):07^0 



Nov 21 2005 4107PM YEE 8. HSSOCIRTES, P.C. (972] 385-77GG 



server list to the client if the client configuration information is not found (Specification, page 21 , 
lines 10-12) 

The means recited in independent claim 21, as well as dependent claims 22-24, may be data 
processing hardware within server 104 or clients 108, 110, and 112 in Figure 1 operating under 
control of software performing the steps described in the specification at page 22, line 12, to page 
24. line 5, or equivalent. A person having ordinary sldll in ttie art would be able to derive consular 
instructions on a computer readable medium as recited in clahn 26 given Figures 9-12 and the 
corresponding description at page 22, line 12, to page 24, line 5, without undue experimentation. 
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CTOIINDS OF REJECTION T O WR REVIEWKD ON APFEAL 
A- GROUND OF REJECTION (CIbIhib 1-26) 

Claims 1-26 are rejected under 35 U.S.C. § 103(a) &s being unpatentable over Chatwani et 
al. (U.S. Patent No. 5,729.685) in view of Wiley et al. (U.S. Patent No. 5,687,320). 
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ARGUMENT 



A- 3S U,S.C- 6 10 ?T Allfegftd Obv<nn5mess> Claims 1>26 

The Office Action rejects claims 1-26 under 35 US.C. § 103(a) as being unpatentable 
over Chatwani et al, (U.S. Patent No, 5,729,685) in view of Wiley et al. (U.S. Patent No- 
5,687,320), This rejection is respDCtfully traversed. 

As to claims 1, 14, and 25, the Office Action states: 

As per claims 1, 14. and 25, Chatwani discloses a method, apparatus and 
computer program product for retrieving client boot infbraiation in a network 
environment with multiple boot servers (col 4, lines 15-18), comprising: 

initiating at a client an initial request (col 29,lines 36-44) for client 
configuration information (alternative embo(timent, col 29, lines 55-67); 

sending from the client the initial request for client configuration 
information to a first boot server (CMS processor is client, fig 26, col 23 lines 1 7- 
26, col 34, lines 30-57 and col 29, Unes 55-67); 

receiWng at the client a boot server list (CMS is acting as a client, col 29) 
if ttie client configuration information is not found on the first boot server (CMS 
functionality is to detemiine correct boot code, boot server, optical path and 
perfonn load balancing, col 30, lines 61-67 and col 32, linesl- 1 1); and 

sending from tfie client a configuration information request (col 26, lines 
12-16) for the client configuration (col 26, lines 12-16) information to each server 
(col 12, lines 5-6) in the boot server list (col 33, lines 16-54, first to next shows 
the order) until the client configuration information is found (col 32, lines 65-67) 
or a request has been sent to every server in the boot server list (fig 23(a)-24, 
clearly shows the CMS is identifying a boot server based on the BFQ message, 
col 33, lines 33-45,col 33, lines 16-54), 

Chatwani may not be using the same terais as claimed, such as initiating at 
a client an initial request for client configuration infomiation; the client 
information is not found on the first boot server, and sending a boot server list to 
the client if the information is not found. However, hiitiating at a client an initial 
request for client configuration information (it is a part of initialization, in a 
client-server model client initiates the request and serves the request), if the client 
information is not foxmd on the first boot server, and sending a boot server list to 
the client if the information is not found (error handling if very well known in the 
art, this may be default choice) are very well known in the art. Wiley, for 
example, discloses as initiating at a client an mitial request for client 
configuration information (col 4, lines 5 1-60); the client information is not found 
on the first boot server (col 4, lines 6-24), and sendhig a boot server list to the 
client if the infbrmation is not found (col 4, lines 6-24), It would have been 
obvious to one of ordinary skill in the art at the time of the hiventlon was made to 
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combine the teachings of Chatwani and Wiley, The motivetion would have been 
to have system where client can obtain an alternate boot sever by requesting the 
boot server list in the case of primary boot server is affected. 

Office Action dated January 6, 2005, pages 3-5. 

Claim 1, which is representative of the other rejected independent claims 14 and 25 with 
regard to similarly recited subject matter, reads as follows: 

1 . A method for retrieving client boot information in a network environment 
with multiple boot servers, comprising: 

initiating at a client an initial request for client configuration information; 

sending from the client the initial request for client configuration 
mfonnation to a first boot server; 

receiving at the client a boot server list if the client configuration 
information is not found on the first boot server; and 

sending fiora the client a configuration information request for the client 
configuration information to each server in the boot server list until the client 
configuration information is found or a request has been sent to every server in 
the boot server list. 

Chatwani and Wiley, taken alone or in combination, fail to teach or suggest if the client 
configuration information is not found on the first boot server, sending fi:om the client a list 
request for a boot server list to the first boot server, receiving at the client the boot server list, 
and sending fi^m the client a configuration information request for the client configuration 
information to each server in the boot server list until the client configuration information is 
found or a request has been sent to every server in the boot server list. 

Chatwani is directed to a method for automatically determining the topology of the 
network, Chatwani provides for the transmitting of link advertisement messages on each of the 
parts of each switch in the network- The link advertisement messages are received by neighbor 
switches and forwaMed to a txtpology manager. The topology manager constructs network 
topology profile information based on received link advertisement messages. Further, the 
topology manager is able to verify bi-direction links based on the received link advertisement 
messages. 

The Ofifice Action alleges that Chatwani teaches initiating at a client an initial request for 
chent configuration information and sending from a client an initial request for client 
configuration information to a first boot server at column 29, lines 36-44; column 29, lines 55- 
67; Figure 26; column 23, lines 17-26; and, column 34, lines 30-57, which read as follows; 

(App^ Brief P^go 10 of 31) 
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A. . Overview of the bootstrapping process 

FIG. 20 is useful for providing an overall flow diagram of the method of 
boostrapping utilisscd in the described system. 

When a switch is first powered up (or when its power is restored after, for 
example, a power failure or when it is reconnected to the network after being 
disconnected for some reason), the switch begins sending out what will be termed 
path access query (PAQ) messages, block 2001. The format for the PAQ 
messages, as transmitted by the booting switch, is found with reference to FIG. 
21(a). PAQ messages are transmitted over each of booting switches ports over the 
meta-topology channel and is received by neighboring switches (assuming there 
ai^ any operational neighboring swiches). The PAQ message is transmitted over 
the topology service channel of each of Ae neighbor svdtch's VSPs through the 
master switch to the CMS. The format for the messages transmitted by the 
neighboring switches is given by FIG. 21(b). The format for messages transmitted 
from the master switch to the CMS is given by FIG, 21(c). 

In response to recelvfaig each PAQ message, the CMS transmits a path 
access response (PAR) message onto the topology service channel of the neighbor 
switch. The format for the PAR messages as transmitted by the CMS is given by 
FIG. 21(d). This message is received by the neighbor switch and transmitted on 
the meta-topology channel to the booting switch using the format given by FIG. 
21(d), block 2002. 

It is worthwhile noting that, in alternative embodiments, some device 
other than the CMS may function to coordinate providing boot code to the 
booting switch. For example, a boot server may, in some embodiments, be 
implemented as an ATM device capable of conununicating directly onto the ATM 
network. In such a case, the boot server may respond to the PAQ messages 
directly by transmitting PAR messages in response to receiving PAQ messages in 
a manner similar to what is described for the CMS. Therefore, the functions 
described herein for the CMS in relation to managing a boot code transfer may 
sometimes be referred to as a boot management. Further, the CMS when 
performing boot functions (and variations of the CMS such as a boot server 
directly providing boot management) may be referred to as a boot manager. 

(Chatwani, column 29, line 28 to column 30, line 2) 
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n^r0 26 

(Chatwani, Figure 26) 

The described embcxiiincnt utilizes the above-described VSP concept to allow for 
dynamic registration of clients and to allow for client-to-client communication 
through cloud 1301, In broad terms, the dynamic client discovery process of the 
described embodiment starts by a client attempting to register itself when it is 
attached to the network and, in response to these attempts, the CMS registering 
the client and allowing later identification of the client by some address type 
(which may be either a logical or physical address) or by identification of a 
switch, module and port. 
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(Chatwani, Column 23, lines 1 7-26) 

FIG. 26 is usefiil for providing a more complete description of the process for 
transfer of the boot file. The booting switch initially generates a request for 
transmission of its boot file using the F-TFTP format, block 2601. The CMS 
receives the request (over the neighbor's VSP as has been described), block 2602, 
and the CMS formats a TFTP request and fonvards the request to the boot server, 
block 2603. The boot server receives the TFTP request and sets up the TFTP 
connection, block 2604. The boot server then transmits a block of boot code to the 
CMS, block 2605. The CMS is responsible for fragmenting the received block 
and transmitting cells containing information from the received block to the 
booting switch over the neighbor's VSP» block 2606. The booting switch responds 
to the CMS with an acknowledgement message when all cells comprising the 
received block have been receive, block 2607. Again, it is noted that the 
acknowledgement message is transmitted over the neighbor's VSP. The CMS 
receives the acknowledgement message and reassembles the acknowledgemart 
message for transmission to the boot server. The acknowledgement message is 
tiien sent to boot server, block 2608. The proems of segmentation of blocks by Ac 
CMS and reeassembly of the blocks by the booting switch (and visa versa) 
follows the fragmented TFTP (F-TFTP) protocol. If there are more blocks of boot 
code to be transmitted, block 2609, the process of the boot server transmitting a 
block and the information in the block being transmitted using F-TFTP protocol is 
repeated 

(Chatwani, column 34, lines 30-57) 

The Office Action alleges that Chatwani's Central Management Supervisor (CMS) is a client In 
column 29, line 28, to column 30, line 2, Chatwani describes that, when a switch powers up, the 
switch sends a path access query (PAQ) message. The PAQ message is sent over neighboring 
switches to the CMS. The CMS then responds to the PAQ message from the switch with a path 
access response (PAR) message with boot code information. In the alternative embodiment, 
Chatwani teaches that some other device, other than the CMS, would act as a boot server and 
provide the boot code to the booting switch. Thus, in Appellants interpretation, the switch is 
acting as the client and the CMS is acting as a boot server, which is contradictory to the OflBce 
Action's allegation. In Figure 26 and the supporting description in column 34, lines 30-57, 
Chatvrani describes a CMS acting as a boot server manager. The CMS docs not initiate a 
request, but, mther, reformats a request from the booting switch and sends it to the boot server. 
The boot server responds to the CMS and the CMS reformats the response and sends it to the 
booting switch. Even if the CMS were considered a client, which it is not, it does not initiate a 



(Appeal Brief Pagel3Gff31) 
Anstndetal.-09/740,26S 

PAGE 1 J/33 ' RCVD AT 11121/2005 4:02:28 PNI [Eastern Slandard rme] ' 8VR:USPTO-EFXRF-6/27* DN1S:2738300 * CSID:972 385 7766 ' DURATION (mni-ss):0740 



Mov 21 2005 4t08Ph YEE & flSSOCIRTES, P.C. (972J 385-77S6 



p. 16 



request for its own configuration, but reformats a request for a booting switches configuration. 
In colunm 23. lines 17-26, Chatwani actually supports AppeUants* assertion that the CMS is not 
a client by stating that the CMS registers the client and allows later identification of the client by 
some address type. Thus, contrary to the Office Action allegation, Chatwani does not teach or 
suggest that the CMS acts as a client 

Chatwani does not teach or suggest receiving at the client a boot server list if the client 
configuration information is not found on the first boot server. The Office Action alleges that 
this feature is taught by the CMS acting as a client in column 29 and the CMS functionality is to 
determine correct boot code, boot server, optical path and perform load balancing, in column 30, 
lines 61-67 and column 32, linesl-1 1, which reads as follows: 

Responsive to receiving the BFQ message, the CMS uses the information 
provided in the menage, including the physical address (field 2141), switch 
hardware version (field 2 142) and switch software version (field 2143) to 
determine the correct boot code download file for the switch to use. The CMS 
then responds with a boot file response (BFR) message in the format given by 
FIG. 21(i) onto the neighbor's VSP boot service channel. The message includes 
the IP address of a boot server (field 2151) and a boot file name (field 2 1 52)- The 
message is received by the nei^bor switch and forwarded on the meta-boot 
channel to the booting switch in the format given by FIG. 21Q), block 2005. 

(Chatwani, column 30, line 61 to column 31, line 5) 

FIG. 21(b) illustrates the format of the PAQ message as it is forwarded on 
the VPI of a neighbor switch. As can be seen, the VPI field 1 12, 1 13 is changed 
by the neighbor switch's switch febric to indicate the neighbor switches VPI and 
the VCI field 114, 1 1 5, 1 16 is changed, again by the neighbor's switch fabric to 
indicate the topology service channel (e.g., 2 in the described embodiment) and 
the port of the neighbor switch on which the PAQ was received. Otherwise, the 
message, and particularly the infomiation field 102, remains imchanged. Thus, the 
PAQ message is switched through the neighbor switch without any requirement 
for intervention by the neighbor switch's controller. 

FIG, 21(c) illustrates the format of the PAQ message as it is received by 
. the CMS. During transmission fi*om the neighbor switch to intermediate nodes 
and onto the CMS. the PAQ's information field is not modified and the only 
modifications arc made in the PAQ's header, by the various intermediate switches 
switch fabrics, to switch the PAQ along the neighbor's VSP until the PAQ arrives 
at the master switch where the VPI 1 12, 1 1 3 is set. by the master's switch febric to 
a value which uniquely identifies the neighbor of the booting switch. 

(Chatwani, column 31, line 64 to column 32, line 18) 
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In column 30, lines 60-67, Chatwani describes the CMS receiving a boot file query (BFQ) 
message from a booting switch. The CMS uses the information provided in the BFQ message to 
determine the correct boot code download file for the switch to use. The CMS then responds to 
the booting switch with a boot file response (BFR) message, The BFR message includes the IP 
address of a boot server and a boot file name. Thus, m this section, Chatwani describes the CMS 
acting as a boot server manager and directs the booting switch to a particular boot server and 
boot file name. Furthermore, there is no boot server list sent to the booting switch (the client) 
only one particular boot server and a boot file name. In column 31, line 64, to column 32, line 
1 8, Chatwani describes a path access query (PAQ) message that is sent from the booting switch 
that is requesting boot code information to the CMS, which acts as the boot server. Additionally, 
this section does not describe a boot server list being returned to the booting switch. Thus, 
nowhere in these sections, or in any other section, does Chatwani teach or suggest receiving, at 
the client, a boot server list if the client configuration information is not found on the first boot 
server. 

The Office Action further alleges that Chatwani teaches sending from the client a 
configuration informatioti request for the client configuration information to each server in the 
boot server list until the client configuration information is found or a request has been sent to 
every server in the boot server list at column 26, lines 12-16, coliunn 12, lines 5-6, column 33, 
lines 16-54, column 32, lines 65-67, which read as follows, and Figures 23a through 24 (not 
shown). 

Assume that client CI 1402 has provided its logical address as "CI" and 
client C2 1403 has provided its logical address as "C2"; Further assume that client 
CI 1402 is attached to port 1 of switch Y 1401 and client C2 1402 is attached to 
port 2 of switch Y 140U The CMS may then store information providing a one- 
to-one correspondence between the logical addresses of the clients and their 
network physical attachment in a client address/location table such as illustrated 
below; 



Logical Address Switch Module 
Port 



CI Y 1 

C2 Y 2 



(Chatwani, column 26, lines 12-23) 
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(3) boot services allowing a controller to dovmload software from the 
supervisor 202 or from a boot file server. 

(Chatwani* column 12, lines 5-6) 

FIG. 21(h) illustrates the fomiat of the BFQ message as it is received by 
the CMS. As can be seen, the message is unchanged from the format of FIG. 
21(g) except for the VPI field 112, 113 being changed as it is transmitted along 
the neighbor's VSF, from one intermediate switch to the next intermediate switch 
and finally to the master switch, where the field is translated by the master's 
switch fabric to indicate a value which uniquely identifies the neighbor switch. 
Again, in the described system, this value is simply the switch number of the 
neighbor switch although b other embodiments it may be a different value in 
which case there would be a requirement for a mapping table or the like at the 
CMS to allow the CMS to identify the neighbor switch. It is advantageous to not 
require the mapping table at least in that more efficient processing can be 
provided because there is not a need to look up a value in the table. 

FIG. 21(i) illustrates the format of a BFR message as it is transmitted by 
the CMS, As discussed above, tiie BFR message provides the booting switch with 
information identifying the boot server and boot file selected by the CMS for 
booting the booting switch. The boot server is identified in field 2151 and the 
boot file name is provided in field 2152, Field 2150 provides identification of the 
output port on which the corresponding BFQ message was transmitted by the 
booting channel. This field is simply echoed by the CMS from field 2140 of the 
received BFQ message. The BFR message also provides the booting switches IP 
address in field 2154 if the booting switch had set field 2125 to zero* The IP 
address is assigned by the CMS from a configuration file based on the physical 
address of the booting switch. 

The VPI field 1 1 2, 1 1 3 is set to indicate the VSP of the neighbor switch 
and the VCI field 1 14, 115, 1 16 is set to mdicate the boot service channel number 
followed by the port number on which the corresponding BFQ was transmitted 

FIG. 210) illustrates the format of the BFR message as received by the 
booting switch. Again, the message is largely unchanged during transmission 
from the CMS except that the VPI field 1 12, 1 13 was altered by the switch fabric 
of the nei^bor switch to indicate the meta path number and the VCI field 1 14, 
1 15, 1 16 is altered to indicate the meta boot channel number. 

(Chatwani, column 33, lines 16-58) 

FIG, 21(f) illustrates the format of a BFQ message as transmitted from the 
booting switch. As was discussed above, the BFQ message is transmitted on one 
port of the booting switch, which port is selected by the booting switch. The 
selection may be based on, among other factors, the cost factor iufoxmation 
provided by the PAR messages. As can be seen, the VPI field 1 12, 1 13 of the 
BFQ message as transmitted from the booting switch is set to the meta path 
number (e.g., 0) and Ae VCI field 1 14, 1 15, .1 16 is set to the meta boot channel 
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number (e.g., 200). The message body includes 5 fields: (1) identification of the 
output port on which the BFQ message was sent by the booting switch, field 
2140; (2) the IP address of the booting switch, field 2125; (3) the physical address 
of the booting switch, field 2141 ; (4) the booting switch hardware version, field 
2142; and (5) the booting switch firmware version, field 2143. The CMS will use 
the infonnation regarding the physical address, hardware version and firmware 
version to determine the correct boot dovmload file for use by the booting switch. 
It is noted that if the switch controller does not have its IP address, it will set field 
2125 to zero indicating to the CMS that it needs its IP address. 

(Chatwani, column 32, line 49 to column 33, line 3) 

As discussed above, in contradiction to the Office Action allegation that the CMS is acting as a 
cheat, nowhere in any section of the Chatwani reference does the CMS hiitiate an initial request 
for client configuration information* Only the booting switch in the Chatwani reference ever 
initiates a request for its own configuration, In column 26, lines 12-16, Chatwani describes the 
CMS storing information providing a one-to-one correspondence between the logical addresses 
of the clients and their networic physical attachment in a client address/location table. In column 
12, lines 5-6, Chatwani describes boot services allovraig a controller to download software fix)m 
the supervisor or fiom a boot file server. In column 33, lines 16-54, and column 32, lines 65-67, 
Chatwani describes the CMS receiving a boot file query (BFQ) message ftom a booting switch. 
The CMS uses the information provided in the BFQ message to determine the correct boot code 
download file for the switch to use. The CMS then responds to the booting switch with a boot 
file response (BFR) message. The BFR message includes the IP address of a boot server and a 
boot file name, Chatwani describes flie CMS receiving a boot file query (BFQ) message from a 
booting switch. Figures 23(a) through 24 do not provide any fiirther teachings of the presently 
claimed invention. In these sections, Chatwani describes a booting switch sending a boot file 
query to the CMS and the CMS directing the booting switch to the server that has the correct 
boot file. The booting switch of Chatwani does not receive a boot server list and does not send a 
configuration infonnation request for the client configuration information to each server in the 
boot server list until the client configuration information is found or a request has been sent to 
every server in the boot server list. 

The Final OfBce Action's allegation that "the CMS is a client," is an inaccurate 
interpretation of tiie actual teachings of Chatwani. Chatwaiu actually supports Appellants 
assertion in column 22, line 66, to column 23, line 26, which reads as follows: 
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As has been discussed, the ATM network comprises switches 
Interconnected in communication with each other through NNIs (and, in the case 
of the netwoik described herein connected in communication with a central 
management supervisor (CMS)) and clients, connected in communication with 
the various switches. Tummg briefly to FIG, 13, above, in connection with the 
discussion of auto-topology, it was shown how the CMS discovers the topology 
of the switches (illustrated as inner cloud 1301). Dynamic discovery of clients 
(shown hi outer cloud 1302) is also an important feature of the described system. 

Often, it is useful for a fast client (e.g. CI) to be able to communicate with 
a second client (e.g., C8) in a network without need for the first client to have an 
understanding of the physical connections of the various switches in the network, 
or even an understanding of where the first client itself is connected within the 
network. This is illustrated by FIG, 1 3 which shows the various switches within a 
cloud 1301. 

The described embodiment utilizes the above-described VSP concept to 
allow for dynamic registration of clients and to allow for client-to-client 
communication through cloud 1301. In broad terms, the dynamic client discovery 
process of the described embodiment starts by a client attempting to register itself 
when it is attached to the network and, in response to these attempts, the CMS 
registering die client and allowing later identification of the client by some 
address type (which may be either a logical or physical address) or by 
identification of a switch, module and port. 

In this section, Chatwani clearly describes that the CMS is a boot server and not a client by 
stating that the CMS registers the client and allows later identification of the client by some 
address type. Thus, contrary to the Final Office Action*s allegation, Chatwani does not teach or 
suggest that the CMS acts as a client. 

The 0£3Bce Action acknowledges that ^'Chatwani may not be using the same terms as 
claimed, such as initiating at a client an initial request for client configuration information; the 
client information is not found on the first boot server, and sending a boot server list to the client 
if the information is not found." However the Office Action alleges that ^'initiating at a client an 
initial request for client configuration information (it is a part of initialization, in a client-server 
model client initiates the request and serves the request), if the client information is not found on 
the first boot server, and sending a boot server list to the client if the information is not found 
(error handling if very well known in the art, this may be default choice) arc vexy well known in 
the art" Appellants respectfully traverse this allegation. Appellants respectfully submit that it is 
not well known in the art to receive at the client a boot server list if the client configuration 
information is not found on the first boot server and send ftom the client a configuration 
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information request for the client cotifiguration information to each server in the boot server list 
until the cUetit configuration infonmation is found or a request has been sent to every server in 
the hoot server list. This is supported at least in the feet that Chatwani does not perform these 
features. The Office Action proffers no other evidence in the prior art that these limitations are 
well-known, or any reasoning to support such a conclusion, other than to summarily dismiss the 
missing elements as well-known. 

The Office Action flirther alleges that Wiley discloses initiating at a cUent an initial 
request for client configuration information and, if the client information is not found on the first 
boot server, sendmg a boot server list to the client at column 4, lines 6-24 and lines 50-61, which 
reads as follows: 

It should be noted that the stifle enable functions to unenable response and 
conversely a stifle unenable enables the response. Thus, when stifle is enabled, 
the host does not respond. 

Hie hosts on the server list are then queried directly in order to obtain 
addresses of the predetermined type of peripheral devices. The client sends a 
message to the affected hosts to provide lists of addresses of the predeteimined 
type of peripheral device, and compiles a list of these addresses. 

The client then sends a second query to the affected hosts whidi requests 
lists of addresses of agents. The client then uses the addresses of agents to query 
the agents to provide the addresses of bootservers for the predetermined type of 
peripheral device. It is possible for the agent to provide addresses of hosts on the 
agent's subnet, or to provide all addresses of bootservers for a selected group of 
peripheral devices of the predetermined type. In the preferred embodiment, the 
e^ent provides all addresses of bootservers for the selected group of peripheral 
devices of the predetermined type. 

(Wiley, column 4, lines 3-24) 

The preferred embodiment of the invention utilizes the fiact that most 
network printers and X-teraiinals utilize one of the following methods to 
configure an IP Address: 

1 . BOOTPD (Boot Protocol DaBmon>-Whenever most network peripheral 
devices power on they broadcast their Link Level Address (LLA) on the network. 
They do so with the hope that a p»rocess on a host on their subnet will be 
configured to listen for their LLA and respond back to it with the peripheral's IP 
Address* BOOTPD is one such process. It utilizes the bootptab file to configure 
its knowledge of LLA/IP Address pairs. 

(Wiley, column 4, lines 49-60) 
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In column 4, lines 3-24, Wiley describes the steps in relation to a client sending out a hale 
message to the boot servers connected to a subnet for information pertaining to tfie existence of 
data listing address of a predetermined type of peripheral device. In response to the hale 
message the boot servers respond ^vith the addresses of the peripheral devices. Once a boot 
server has responded, the client sends out a stifle message to the servers who have responded so 
the servers may ignore future hale messages. After all servers have responded, the client sends 
out anodier message to cancel tiie stifle message. In colunm 4, lines 5 1-60, Wiley describes a 
boot protocol daemon that provides a bootptab file to the peripheral device. However, Wiley 
ftirther teaches in column 4, lines 39-48, that the response from an agent (computer device) is a 
single client-agent relationship, rather than permitting an agent to request addresses from other 
agents. 

Thus, Wiley teaches a client building a list of servers and agents (computer devices) to 
determine the boot servers that will be used for peripheral devices. Then, as an additional 
peripheral device is added to the client, the client will automatically know, based on the list, 
what server or agent to go to directly to fiiKl the appropriate boot code. While Wiley may teach 
initiating at a client an initial request for client configuration information and sending from the 
client the initial request for client configuration bformation to a first boot server, that would be 
the only boot server that the request is sent to as the client has previously built, on its own^ a list 
of the agent or server that has tfie appropriate boot code. 

Wiley does not teach or suggest receiving at the client a boot server list if the client 
configuration information is not found on the first boot server and sending fi:om the client a 
configuration information request for the client configuration information to each server in the 
boot server list until the client configuration information is found or a request has been sent to 
every server in the boot server list As discussed above, the client of Wiley builds the list as a 
precursor to adding a peripheral device and has no need to send further configuration requests as 
it knows prior to the peripheral being added on which server the configuration will be stored. 

Thus, Cbatwani and Wiley, either alone or in combination, are simply not relevant to the 
claimed invention beyond merely mentionmg some of the elements of the presently claimed 
invention. That is, Cbatwani and Wiley, taken alone or in combination, do not teach receiving at 
the client a boot server list if the client configuration information is not found on the first boot 
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server and sending from the client a configuration information request for the client 
configuration infoitnation to each server in the boot server list until the client configuration 
information is found or a request has been sent to every server in the boot server list. Thus. 
Appellants respectfully submit that Cbatwani and Wiley, either alone or in combination, do not 
teach or suggest all of the features of independent claims 1, 14, and 25. 

Independent claims 10, 2 1, and. 26 recite similar features in their respective claim 
terminology. For example, claim 10. which is representative of the other rejected independent 
claims 21 and 26 with regard so similarly recited subject matter, recites "receiving at a boot 
server an initial request for client configuration information from a client, wherein the initial 
request is initiated at a client and sending from the boot server the boot server list to the client if 
the client configuration information is not found." 

Furthermore^ there is not so much as a suggestion in either reference to modify the 
references to include such features. That is, there is no teaching or suggestion in Chatwani or 
Wiley that a problem exists for which receiving at the client a boot server list if the client 
configuration information is not found on the first boot server and sending firom the client a 
configuration infomiation request for the client configuration information to each server in the 
boot server list until the client configuration mformation is found or a request has been sent to 
every server in the boot server list, is a solution. 

Moreover, neither reference teaches or suggests the desirability of incorporating the 
subject matter of the other reference. That is, there is no motivation offered in either reference 
for the alleged combination* The Office Action alleges that the motivation for the combination 
is **to have system where client can obtain an altemate boot sever by requesting the boot server 
list in the case of primary boot server is afiected." As discussed above, Chatwani merely uses a 
CMS to operate as a boot server or a boot server manager and maintains a boot server list. Wiley 
merely describes building a list of boot servers on the client and then referencing the list as 
additional peripheral devices are added. Neither reference receives at the client a boot server list 
if the client configuration infomiation is not found on the first boot server and sends from the 
client a configuration information request for the client configuration information to each server 
in the boot server list until the client configuration information is found or a request has been 
sent to every server in the boot server list. Thus, the only teaching or suggestion to even attempt 
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the alleged coinbination is based on a prior knowledge of Appellants* claimed invention thereby 
cotistitiiting impennissible hindsight reconstruction using Appellants' own disclosure as a guide. 

Thus, Chatwani and Wiley, taken alone or in combination, do not teach or suggest all of 
the features in independent claims 1, 10, 14, 21, 25, and 26 as is reqiUred under 35 U.S.C. § 
103(a). At least by virtue of their dependency on independent claims 1, 10, 14, and 21, the 
specific features of claims 2-9, 11-13, 15-20, and 22-24 are not taught by Chatwani and Wiley, 
either alone or in combination. Accordingly, AppeUants respectfully tequest that the rejection of 
claims 1-26 under 35 U.S.C. § 103(a) not be sustatoed. 

CONCLUSION 

In view of the above, Appellants respectfully submit that claims 1-26 are allowable over 
the cited prior art and that the application is in condition for allowance. Accordingly, Appellants 
respectfully request the Board of Patent Appeals and Interferences to not sustain the rejections 
set forth in the Final Office Action. 



Francis Latnmes 
Reg. No. SS,3S3 

& Associates, P.C. 
PO Box 802333 
Dallas, TX 75380 
(972) 385-8777 
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gL ^OMS APPENDIX 

The text of the claims involved in the appeal aic: 

1 . A method for retrieving client boot infomiation in a network environment with mtiltiple 
boot servers^ comprising: 

initiating at a client an initial request for client configuration information; 
sending from the client the initial request for client configuration information to a first 
boot server, 

receiving at the client a boot server list if the client configuration information is not 
found on the first boot server; and 

sending from the client a configuration information request for the client configuration 
information to each server in the boot server list until the client configuration information is 
fotind or a request has been sent to every server in the boot server list 

2. The method of claim 1. wherein at least one of the initial request, the list request, and the 
configuration information request ifi a trivial file transfer protocol request. 

3. The method of claim U further comprising: 

receiving, from the first boot server, an error message that indicates that the client 
information is not found on the first boot server. 
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4. The method of claim 1 , further comprising: 

receiving the client configuration information from an associated boot server in response 
to the client configuration information being found. 

5. The mediod of claim 4, further comprising: 

sending a hoot file request for remaining boot files to the associated boot server based on 
the client configuration information. 

6 . The method of claim 1 , further comprising: 

determining whether the entries in the boot server list were pre-ordered, in order to better 
support load balancing among boot servers, prior to transmission to the client; and 

if the list is found to be ordered, sending a configuration information request for the 
client configuration information to each server in the boot server list in the order given. 

7. The method of claim 1 • fbrther comprising; 

sending a oonfiguration information request for the cUent configuration information to 
each server in the boot server list in order of increasing network distance, where distance is 
estimated fix)m available network configuration information when there was no indication that 
the order of the original boot server list was optimi2ed in order to better support load balancing, 

8 . The method of claim 1 , wherein the method is performed by a network bootstmp 
program. 
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9. The method of claim 1, wherein the method is performed on a client computer. 

1 0. A method for providing client boot information in a network environment with imiltiple 
boot servers, comprising: 

receiving at a boot server an InitiBl request for client configuration information from a 
client, wherein the initial request is initiated at a chent; and 

sending from the boot server the boot server list to the client if the client configuration 
information is not found 

11. The method of claim 10, wherein at least one of the initial request and the list request is a 
trivial file transfer protocol requiest, 

12. The method of claun 10, flirther comprising: 

adding an indication to the boot server list to inform the client that the list is being 
provided in optimal order to support load balancing among boot servers. 

1 3 . The method of claim 10, wherein the method is performed on a boot server, 

14. An apparatus for retrieving client boot infbrmation in a network environment with 
multiple boot servers, comprising: 

initiating means for initiating at a client an initial request for client configuration 
information; 
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first sending means for sending from a client an initial request for client configuration 
information to a first boot server, 

receipt means for receiving at the client a boot server list if the client configuration 
information is not found on the first boot server; and 

second sending means for sending from the client a configuration information request for 
the client configuration information to each server in the boot server list until the client 
configuration information is found or a request has been sent to every server in the boot server 
list. 

15. The ^paratus of claim 14, wherein at least one of the initial request, the list request, and 
the configuration information request is a trivial file transfer protocol request. 

1 6. The apparatus of claim 14, fUfther comprising: 

means for receiving, from the first boot server, an error message that indicates that the 
client information Is not found on the first boot server. 

1 7. The apparatus of claim 14^ fiuther con^Trising; 

means for receiving the client configuration information, from an associated boot server 
in response to the client configuration information betog found; and 

means for sending a boot file request for remaining boot files to the associated boot 
server based on the client configuration information. 
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18, The apparatus of claim 14, further comprising: 

means for determining whether the entries in the boot server list were pre-ordered, in 
order to better support load balancing among boot servers, prior to transmission to the client; and 

if the list is fowd to be ordered, means for sending a configuration information request 
for the client configuration information to each server in the boot server list in the order given, 

1 9, The apparatus of claim 14, further con^sing: 

means for sending a configuration infbnnation request for the client configuration 
infonnation to each server in the boot server list in order of increasing network distance, where 
distance is estimated flfom available network configuration information when there was no 
indication that the order of the original boot server list was optimized in order to better support 
load balancing. 

20. The apparatus of claim 14, wherein the apparatus is client computer running a network 
bootstrap program. 

21. An apparatus for providing client boot inforraation in a network environment with 
multiple boot servers, comprising: 

receipt meanis for receiving at a boot server an initial request for client oonfiguration 
infonnation from a client, wherein the initial request is initiated at a client; and 

sending means for sending from the boot server the boot server list to the client if the 
client configuration information is not found. 

(Appeal Brief Page 27 of 31) 
Anandetal.- 09/740^ 

PAGE 29m^RCVDAT11121/2005 4:02:28PM [Eastern Standard m 385 7766* DURATION (mm-ss):0740 



Mov 21 2005 4jl2Ph YEE 8. RSSOCinTES, P.O. (972J 385-776G 



P 



22. The apparatus of claim 21 , wherein at least one of the initial request and the list request is 
a trivial file transfer protocol request. 

23. The apparatus of claim 21 , further comprising: 

means for adding an indication to the boot so^er list to inform the client that the list is 
given in optfanal order to support load balancing among boot servers. 

24. The apparatus of claim 2 1 , wherein the apparatus is a boot server. 

25 . A computer program product, in a computer readable medium, for retrieving client boot 
information in a network environment with multiple boot servers, comprising: 

instructions for initiating at a client an initial request for chent configuration information; 

instructions for sending from a clietit an hiitial request for client configuration 
information to a first boot server; 

instructions for receiving at the client a boot server list if the client configuration 
information is not found on the first boot server; and 

instructions for sending from the client a configuration information request for the client 
configuration information to each server in the boot server list vintil the client configumtlon 
Information is found or a request has been sent to every server in the boot server list. 

26. A computer program product, in a computer readable medium, for providmg client boot 
information in a network environment with multiple boot servers, comprising: 
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instructions for receiving at a boot server an initial request for client configuration 
information from a client, wherein the initial request is initiated at a client; and 

instructions for sending from the boot server the boot server list to the client if the client 
configuration information is not found 
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V.VTDENCE APPENDIX 
There is no evidence to be presented. 
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RELATED PROCEEDINGS APPENDIX 
There are no related proceedings. 
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